Description

Fixes #9379 — the recursive Unknown event: response:response:...:execute/cleanup storm in browser mode.

Root cause (traced)

My earlier explanation (BroadcastChannel echoing to the sender) was wrong, as pointed out in review — thanks. The actual mechanism:

1. The orchestrator creates tester iframes with src = "/?sessionId=<id>&iframeId=<id>" (createTestIframe, packages/browser/src/client/orchestrator.ts).
2. The dev server serves a fully functional tester page to any window that requests / with a live sessionId (packages/browser/src/node/serverTester.ts).
3. An anchor's href="" resolves to the current URL including the query string. So a test that clicks <a href="" target="_blank"> — or ctrl/meta-clicks a relative link, which routers deliberately don't preventDefault() — opens a popup at the tester URL. The popup boots a second, top-level tester with the same sessionId and the same iframeId, joining the same BroadcastChannel.

From then on the two same-iframeId testers ping-pong:

• The popup posts ready. The real tester receives it (the iframeId check passes — it's its own id), posts ack:ready, falls into the default: case (Unknown event: ready), and the finally block posts response:ready.
• The popup receives ack:ready and response:ready and does the same. Every received message spawns an ack: and a response: in the twin, so growth is exponential: ack:response:response:ack:...:ready.
• The storm also starves the real tester, so the run additionally fails with The iframe ... did not acknowledge the "cleanup" message within 60000ms.

The orchestrator already ignores response:/ack: events in its default: case ("ignore acknowledgements and responses to events we sent", added in #10656); the tester side had no equivalent protection against a duplicate participant.

This also explains the coverage report in #9379 (grant-progress): anything that opens the tester URL in a second browsing context triggers the same loop.

Fix

The tester only participates in the iframe channel when it is actually embedded in the orchestrator (window.self !== window.top): a top-level copy of the page neither handles channel messages nor announces ready. This removes the duplicate participant instead of filtering event names, addressing the review feedback that the previous startsWith('response:') guard only hid the symptom.

Numbers (fixture: one test clicking <a href="" target="_blank"> + one trivial follow-up file, chromium)

Regression test

test/browser/specs/duplicate-tester.test.ts (same style as specs/readiness.test.ts): runs the popup-click scenario inline and asserts no Unknown event in stderr, exit code 0, and both tests passing.

Verified failing without the fix and passing with it on chromium, firefox and webkit:

• unfixed: chromium exit 1 (579k Unknown event errors in ~42s), webkit exit 1 (446k errors), firefox exit 1 (inner run flooded until the spec's 60s timeout)
• fixed: all three pass in 2–4s; specs/readiness.test.ts (3 tests over the same handshake machinery) still passes on all three

AI disclosure

Root-cause tracing, the fix, and the regression test were developed with assistance from Claude Code; I reviewed all changes and the verification runs above were executed locally.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci. (duplicate-tester + readiness specs verified on chromium/firefox/webkit; a full local test/browser run hits pre-existing failures that reproduce identically on unmodified main in my environment, so relying on CI for the full matrix)

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable way. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.